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DESCRIPTION 

USAGE DATA HARVESTING 



5 The present invention relates to methods for collection of data relating 

to selections made by a user and to apparatuses supporting the same. In 
particular, although not exclusively, the invention relates to the gathering of 
usage data for broadcast television receivers. 

io It is possible for a set top box (or any other broadcast television 

receiver) to record the actions of the consumer, such as which channels they 
watch and when they watch them. When this set top box is connected to a 
return channel, this information could be transferred from the set top box to 
another party. 

15 This information is useful to companies such as broadcasters for 

analysing viewing demographics, and for targeting consumers with offers and 
services that might be of interest to them. For the consumer, however, there 
are privacy issues with the use of their viewing habit information and this can 
lead to a reluctance on the part of users to make their information available. 

20 

It is an object of the present invention to at least partially address the 
above mentioned issue. 

In accordance with a first aspect of the present invention there is 
provided a method of harvesting usage data from a broadcast receiver 
25 configured to detect and store such usage data, comprising: 

providing to said receiver a privacy policy identifying the usage data 
sought to be harvested and the intended use for such data; 

at said receiver determining whether a received privacy policy is 
acceptable; and 

30 if acceptable, at the receiver selecting from store the usage data 

identified in the privacy policy and transmitting the same to the sender of the 
privacy policy. 
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By delivering a privacy policy specifying the use the data is to be put to, 
the user is better able (and more likely) to opt for acceptance. At the same 
time, the policy provides a specification to the receiver as to which harvested 
data (which may be only a small subset of the data gathered by the receiver) is 
to be transmitted. 

The receiver may present a received privacy policy to a user, with 
acceptance or otherwise of said policy being determined by user input: in such 
a case, the receiver may format the received privacy policy prior to 
presentation to the user, for example to present simple lists of the information 
required or the intended use(s) to make it more readily understandable by the 
user. Alternatively, the receiver may store privacy policy preference data for a 
user and, based on the same, determine automatically whether a received 
privacy policy is acceptable. With such a pre-stored preference profile, the 
user is not required to interact each time a data gathering request (in the form 
of a privacy policy) is received. 

As the user may not be satisfied with the basic information carried by 
the privacy policy, the step of determining acceptance may include a process 
of negotiation between the receiver user and the sender of the privacy policy, 
for example to enable the user to find out more about the intended use and/or 
destination of the data. 

A received privacy policy may be partly accepted, with only a part of the 
requested usage data being transmitted as a result. For example, a user may 
be willing to share data about receiver usage (such as which programmes are 
watched or recorded) but unwilling to share personal data such as name, age 
or gender. To counter such worries, the receiver may remove direct identifiers 
for the user from the usage data prior to transmitting to the sender of the 
privacy policy. Such removal may comprise simple deletion or replacement by 
a pseudonym or other dummy data. 

In one example use of the present invention, the sender of the privacy 
policy provides conditional access broadcast services and access thereto is 
conditional on user acceptance of the privacy policy and transmission of the 
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usage data. By providing such an incentive, users may be encouraged to 
make their data available. 

Also in accordance with the present invention there is provided an 
apparatus for harvesting of usage data comprising: 
5 a broadcast receiver (which may be a broadcast television receiver); 

monitoring and storage means coupled with said broadcast receiver and 
arranged to detect and store usage data relating to a users operation of said 
receiver; 

an input to receive a privacy policy identifying usage data sought to be 
10 harvested and the intended use for such data; 

control means coupled with said input and said storage means and 
operable to determine whether a received privacy policy is acceptable; and 

an output connectable to a back channel to the source of the privacy 

policy, 

15 the control means being arranged, on determination that said received 

privacy policy is acceptable, to select from said storage means the usage data 
identified in the privacy policy and transmit the same to the output. 

These and other aspects of the present invention are recited in the 
appended claims which are incorporated herein by reference and to which the 

20 reader is now referred, and/or are described in the following description of 
embodiments of the invention. 

Embodiments of the present invention will now be described by way of 
example only with reference to the accompanying drawings in which: 
25 Figure 1 schematically represents a series of interactions between a 

broadcaster ancT a receiver embodying the present invention; 

Fi gure 2 is a flow chart illustrating alternative steps that may be carried 
out at the receiver side in Figure 1 ; and 

Figure 3 schematically represents functional features of an apparatus 
30 embodying the present invention. 
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Within this description, the term broadcaster will be used generally to 
indicate a company or other body that desires to obtain viewer profile 
information. The will be many different types of company who may desire 
profiling information, but a broadcaster is a likely first user, and using the term 
broadcaster helps to clarify the following. 

Referring initially to Figure 1, a series of interactions between a 
broadcaster (to the left of the Figure) and a receiver (to the right) are 
illustrated. Initially, the broadcaster transmits 10 one or more broadcast data 
streams. At the receiver, a selection 12 is made, typically in response to user 
input, as to which stream (e.g. which television channel) is watched or 
recorded. Within the receiver, a record 14 is made of such selections in non- 
volatile storage to build up a picture of the users viewing habits, which 
information is of interest to the broadcaster to enable improved scheduling of 
programmes, targeting of special offers and so forth. 
15 Before the broadcaster can receive viewer usage information, they have 

to create 16 a privacy policy file. The privacy policy file describes all the items 
of information that the broadcaster wishes to receive, and the intended use for 
this information. In the following example, the W3C standard P3P (Platform for 
Privacy Preferences) is used, as described at http://www.w3.org/TR/P3P, but 
20 other representations would be equally applicable. 

<POLICIES xmlns="http://www.w3.org/2002/01/P3Pvl"> 
< POL ICY name=" sample" 

discuri="http : / /www . example . com/viewing-policy . html " 
25 opturi="http : //www . example . com/opt . html"> 

<ENTITY> 

<DATA-GROUP> 

<DATA ref="#business .name">Example, Corp.</DATA> 
<DATA ref="#business . contact- 
30 info . online . email ">privacy@example . com</DATA> 

</DATA-GROUP> 
</ENTITY> 

<ACCESSXnone/X/ACCESS> 
<DISPUTES-GROUP> 
35 <DISPUTES resolution-type=" service" 

service="http : / /www . example . com/privacy . html " 
short-description=" Please contact our customer service desk 

with privacy concerns by emailing 
privacyGexample . com" /> 

40 </DISPUTES-GROUP> 
< S T ATEMENT > 
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<PURPOSE><admin/><pseudo-analysis/></PURPOSE> 
<RECIPIENTXours/X/RECIPIENT> 
<RETENTIONXindefinitely/X/RETENTION> 
<DATA-GROUP> 

<DATA ref="#user .gender"> 

<CATEGORIESXdemographic/X/CATEGORIES> 
</DATA> 

<DATA ref="#user .name. family "> 

<CATEGORIESXdemographic/X/CATEGORIES> 
</DATA> 

<DATA ref="#user . name . given" > 

<CATEGORIESXdemographic/X/CATEGORIES> 
</DATA> 

<DATA re f="# dynamic. interactionrecord"> 

<CATEGORIESXinteractive/Xnavigation/X/CATEGORIES> 
</DATA> 
</DATA-GROUP> 

< DATA- GROU P base="http: //www . tv-anytime . org/usage-history-p3p- 

scherna"> 

20 <DATA ref="#av.playrecording"/> 

<DATA ref-"tav. plays tream"/> 
<DATA ref="#av. record" /> 
<DATA ref="#video. slowmotion"/> 
<DATA ref="#data. archive" /> 
25 </DATA-GROUP> 
</STATEMENT> 
</POLICY> 
</POLICIES> 

30 Whilst a detailed discussion of the above example is not necessary, 

some of the parts will now be identified for the purposes of illustration. 

DATA ref= 

These references identify the data sought, such as user name and 
gender, times and dates for watching taped audio/video (AV) content or for 
35 watching or taping live AV content. 

DISPUTES resolution-type= 

Specifies a mechanism for negotiating or otherwise seeking data about 
the privacy policy/data harvesting request. In the above example, this is in the 
form of an e-mail address for a customer service desk. 

40 RECIPIENT 

Who will receive the data. 

RETENTION 

How long the data will be held by the recipient (indefinitely in the above 
example). 

CATEGORIES 
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Identifies the intended use for the data (for demographic profiling in this 
example). 

Once this policy file has been created, it needs to be transferred 18 to 
the consumer's set top box. The exact details of this transfer are outside of the 

5 scope of this invention, but the skilled reader will be aware of suitable 
mechanisms for transferring data (in conjunction with the broadcast data or 
separately) to the receiver. 

Once received 20 by the consumer's receiver device, the next step 22 is 
determining whether or not the stated requested data and its intended uses 

10 are acceptable to the user. In an interactive mode, the privacy policy could be 
displayed to the user (suitable reformatted in some easier to understand form 
that raw XML), with user input 24 indicating acceptance or otherwise. 
Alternatively, in a system check 26 a software agent or routine on the device 
can make a decision on the policy file based on previous configuration (stored 

is privacy policy preference data) by the consumer. The determination may 
include a negotiation or explanation step with the user contacting the 
- broadcaster 38, for example to seek further information about the intended use 
and/or destination of the user data. As indicated by arrow 42, this process 
may conceivably result in the broadcaster reviewing or amending the privacy 

20 policy. 

When the viewing history is transferred 28 from the consumer to the 
broadcaster, the policy file is used to filter 30 the viewing history. For example 
if the policy file indicated that only information about what programmes had 
been watched was required, all other information in the viewing history would 

25 be removed before transfer. 

If the purpose of the viewing history is for anonymous profiling (the 
purpose is specified in the policy file) the set top box can replace 32 any user- 
identifiable information (such as name, user id, etc) with pseudonyms to 
ensure that the broadcaster cannot use the viewing history for direct viewer 

30 analysis. 

If a consumer is going to allow their viewing history to be distributed, 
they will almost certainly be getting some benefits in return. When the 
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consumer subscribes to this beneficial service, the broadcaster could transmit 
their privacy policy file to the consumer. Ancillary information would need to 
be carried along with the privacy file to indicate if acceptance of this policy was 
a pre-requisite of using their service, or merely optional. As indicated 

5 generally at 34 and 36, on receipt of usage data, the broadcaster may make 
available a benefit such as access to conditional access services, such as 
subscriber broadcast channels. 

Figure 2 illustrates a variation in the process followed by the receiver in 
Figure 1 . Following receipt of the privacy policy at 28, a first acceptance test 

10 22. A (which may be interactive or automated as described above) is 
performed. This test looks for acceptance of all the specifications (data types, 
intended use, retention time and so forth) identified in the privacy policy. If the 
test is met, then all the required data is selected 30.A from that held by the 
receiver and sent 28 to the broadcaster. If the test 22. A fails however, a 

15 second test 22.B is made for partial acceptance, for example to determine if 
the user is willing to submit some of the requested data (which may still have 
value for the broadcaster). If the second test 22.B fails, the process stops 40 
and no data is sent to the broadcaster. If the second test is successful, 
however, the selection 30.B from the stored data comprises just that data that 

20 the user is prepared to submit, which data is then sent 28 as before. 

Figure 3 schematically represents functional features of an apparatus 
suitable to embody the present invention and support the above described 
method for harvesting of usage data. The basic requirements of the apparatus 
are that it is capable of receiving broadcast data (broadcast television signals 

25 in this example), that it includes persistent storage of usage history, and that it 
is connectable to a return channel (for example via modem or broadband 
internet connection) for delivery of the usage data to the broadcaster or other 
source of the privacy policy. 

In the apparatus of Figure 3, a broadcast receiver 50 has an input 52 to 

30 receive broadcast television signals. This input 52 may be an aerial as shown, 
or it may for example comprise a satellite dish or connection to a terrestrial 
cable television network. A monitoring stage 54 with associated non-volatile 
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storage (for example a local hard disk drive) 56 is coupled with the receiver 50. 
In use, the monitor stage 54 detects the viewing information in terms of what 
channel and programme is being watched, and saves this usage data in store 
56. The apparatus has an input to receive the privacy policy: in the example 
shown, the privacy policy is delivered by the same means as the broadcast 
data, and so input 52 is used. Where an alternative delivery mechanism is 
used for the privacy policy, a separate input (not shown) may be provided. 

A control stage 58 (which may suitably be provided by a microcontroller 
or other processor device) is coupled with the input 52 for the privacy policy 
(via the receiver 50 in this instance). The control stage 58 is also connected to 
the store 56 and operates to determine whether a received privacy policy is 
acceptable and, if so, to select from the store 56 the usage data identified in 
the privacy policy. An external interface 60 coupled with the control stage 58 
provides an output connectable to a back channel to the source of the privacy 
policy. 

An output device 62 in the form of a display (which may be integral with 
the receiver apparatus or coupled externally) permits the control stage 58 to 
present a received privacy policy to a user, suitably following reformatting to 
make it easier for an unskilled user to comprehend. A user input device 64 
provides a means by operation of which a user determines acceptance or 
otherwise of the policy in an interactive acceptance test as described 
previously. For the automated acceptance test, the store 56 holds the privacy 
policy preference data for a user and, based on the same, the control stage 58 
determines automatically whether a received privacy policy is acceptable. 

In the foregoing we have described a method of harvesting usage data 
from a broadcast receiver configured to detect and store such usage data 
comprises providing to the receiver a privacy policy identifying not only the 
usage data sought to be harvested but also the intended use for such data. At 
the receiver, an interactive or automated determination is made as to whether 
a received privacy policy is acceptable; and if so, the receiver selects from 
store the usage data identified in the privacy policy and transmits the same to 
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the sender of the privacy policy. A receiver apparatus configured to support 
the method is also provided. 

From reading the present disclosure, other modifications will be 
apparent to persons skilled in the art. Such modifications may involve other 
5 features which are already know in the field of data harvesting, methods and 
apparatuses supporting the same, and applications thereof, and which may be 
used instead of or in addition to features already described herein. 



